1. Field of the Invention
The present invention is directed to distributed transaction processing systems and more specifically relates to a system for automatically configuring a user-developed application so that the application is capable of requesting execution of a transaction across several hardware platforms.
2. Description of the Prior Art
On-line transaction processing (OLTP) is a technology that has been used successfully for business-critical application by large enterprises for many years. With OLTP, users at terminals send messages to application programs, and these in turn update databases in real time. This is in contrast to batch or queued processing of transactions where the transactions are processed at a later time.
An example of an OLTP application is an airline reservation system, When a travel agent sends a request to reserve a seat on a plane, a database is updated accordingly, and a confirmation message is sent back to the agent's terminal. All of the tasks are part of a single transaction, and many agents can perform transactions at the same time. OLTP systems are typically used in environments that support large numbers of users, all accessing the same database, with hundreds and sometimes thousands of transactions taking place each second. The systems are typically based on large enterprise servers that can provide the performance, reliability, and data integrity demanded by these environments.
A transaction may be thought of as a set of actions performed by a transaction processing system wherein the actions together exhibit the properties of Atomicity, Consistency, Isolation, and Durability (ACID). The following definitions are given in Transaction Processing: Concepts and Techniques, by Jim Gray and Andreas Reuter, Morgan Kaufmann Publishers, Inc., 1993, p.6:
Atomicity. A transaction's changes to the state are atomic; either all happen or none happen. These changes include database changes, messages, and actions on transducers.
Consistency. A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.
Isolation. Even though transactions execute concurrently, it appears to each transaction, T, that other transactions execute either before T or after T, but not both.
Durability. Once a transaction completes successfully, (commits), the state of the data is changed to reflect the successful completion of the transaction, and the state of the data will survive system failures.
To maintain the properties identified above, at the beginning of processing a transaction, a transaction processing application program typically invokes some form of begin-transaction function to indicate that processing of a transaction has begun. This operation is typically logged to an audit file to demarcate the operations associated with the particular transaction. Following the begin-transaction function, the other functions associated with the application-defined transaction are performed and are also logged to an audit file. If all operations associated with a transaction complete successfully, a commit function is invoked to make permanent any state changes that have occurred as a result of the transaction. The commit operation is logged to the audit file to indicate that all operations have completed successfully. If an error occurs during processing of the transaction and a commit operation is not performed, a rollback function is invoked to undo the effects of the operations performed to that point in processing the transaction.
Distributed Transaction Processing (DTP) is a form of on-line transaction processing that allows a single transaction to be performed by multiple application programs that access one or more databases on one or more computers across a network. This type of transaction, in which multiple application programs cooperate, is called a distributed transaction. Using DTP, for example, related databases at regional and branch locations can be synchronized. DTP also facilitates transaction processing across multiple enterprises. For example, DTP can be used to coordinate the computers of manufacturers and suppliers, or to coordinate the computers of enterprises in related industries, such as the travel agency, airline, car rental, and hotel industries.
Transaction processing in a distributed environment can be either non-global or global. In a non-global transaction, the same work takes place as in a traditional transaction, but the work is distributed in a client/server manner. For example, a travel agent may request an airline reservation via a client application program that has a graphical user interface (GUI). The client application program communicates with a server application program that manages the reservation database. The server application program updates the database, commits or aborts its own work, and returns information to the client application program, which notifies the travel agent.
A global transaction consists of multiple, coordinated database updates, possibly occurring on different computers. Global transactions are used when it is important that all databases are synchronized so that either all updates are made or none are made. Continuing with the previous example, the travel agent may also need to reserve a rental car and hotel room. The customer who is traveling wants to make sure that all reservations are coordinated; if a flight is unavailable, the hotel and car reservations are not needed. For the purpose of illustrating a global transaction, the airline, car, and hotel databases are on different transaction processing systems.
The global transaction begins when the travel agent requests the reservation from a workstation client application program with a graphical user interface. The client program contacts three server application programs on different transaction processing systems. One server program books a flight, another reserves a car, and the third makes a hotel reservation. Each of the server application programs updates its respective database. The transactions processed by each of the server application programs may be referred to as subordinate transactions of the global transaction. A global transaction manager coordinates the updates to the three databases, and a subordinate transaction manager on each of the individual transaction processing systems coordinates locally with the server application programs. The server application programs return information to the client application program.
A major advantage of global transaction processing is that tasks that were once processed individually are processed as a group, the group of tasks being the global transaction. The database updates are made on an all-or-nothing basis. For example, if an airline seat is not available, the hotel and car reservations are not made. Thus, with a global transaction, tasks that were once performed independently may be coordinated and automated.
As with non-global transactions, global transactions must possess the ACID properties. In order to preserve the ACID properties for a global transaction, the commit processing is modified to a two-phase commit procedure. Under a two-phase commit, a global transaction manager first requests that each of the subordinate transaction managers prepare to commit their updates to the respective databases. If all the local transaction managers respond that they are prepared to commit, the global transaction manager sends a commit request to the local transaction managers. Thus, the two parts of the two-phase commit process are (i) prepare to commit the database updates, and (ii) commit the database updates. If any one of the transaction managers is unable to prepare to commit, the entire global transaction is aborted and each transaction manager performs a rollback function to undo the processing that may have occurred up to that point. In short, the two-phase commit process ensures that multiple databases participating in a single global transaction are synchronized - either all database updates requested by the global transaction are made or, in the event of system or component failure, none are made. Two-phase commit guarantees global data integrity and preserves the ACID properties in a DTP environment.
An industry consortium of users and vendors, known as X/Open.TM., has developed a model architecture for DTP, referred to as the X/Open Distributed Transaction Processing model. The X/Open DTP model is a software architecture that allows multiple application programs to share resources provided by multiple resource managers, and allows their work to be coordinated into global transactions. The X/Open DTP model comprises a number of components, application programming interfaces, and communications interfaces.
FIG. 1 illustrates a client system 10 and a server system 12 both constructed in accordance with the X/Open DTP model architecture. Referring to the client system 10 as an illustrative example, the components of the X/Open DTP model include an application program (AP) 14, one or more resource managers (RMs) 16, a Transaction Manager (TM) 18, and a Communications Resource Manager (CRM) 20.
An Application Program (AP), such as client application program 14, is a user-defined software component that defines global transaction boundaries and specifies actions that constitute global transactions. It also provides access to one or more resources that are required by a transaction. In a global transaction, two or more APs perform their individual functions which, when combined, make up the global transaction. One of the APs will be the transaction coordinator, that is, the AP that starts and finishes the global transaction. The other APs will be subordinate.
A Resource Manager (RM) 16 provides access to a resource for the AP 14. The X/Open DTP model permits multiple resource managers. Database management systems and file access systems are examples of system software components that act as RMs.
The APs begin and end transactions under the control of the Transaction Manager (TM) 18. The TM 18 is a system software component that assigns transaction identifiers to global transactions, monitors their progress, coordinates their completion, and coordinates failure recovery. The TM enforces the transaction property of atomicity. In a global transaction, the TM adheres to the two-phase commit transaction processing protocol.
The CRM 20 controls communication between the AP 14 and other APs (e.g. AP 40) that are participating in global transactions, as well as between the TM 18 and TMs on separate data processing systems (e.g. the TM of system 12).
The X/Open DTP model provides a number of standard application programming interfaces that enable application programs to interact with system components to conduct global transactions. These application programming interfaces include one or more AP-RM interfaces 22, an AP-TM interface 24, an AP-CRM interface 26, an RM-TM interface 28, and a TM-CRM interface 30.
The AP-RM interfaces 22 provide the AP 14 with access to resources (such as databases) through their respective RMs 16. These interfaces are not specifically defined by the X/Open DTP model, as a number of different resources can exist on a system. Examples of AP-RM interfaces include the Structured Query Language (SQL) and the Indexed Sequential Access Method (ISAM).
The AP-TM interface 24 is provided by the TM 18 to define global transaction boundaries. The AP-TM interface is also referenced as the TX interface. Further information on the TX interface is available in Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992). The TX interface is described in somewhat greater detail below.
The AP-CRM 26 interfaces are provided by the CRM 20 to the AP 14. The X/Open DTP model supports the following three AP-CRM interfaces: the Tx RPC interface, the XATMI interface, and the CPI-C interface. Each of these interfaces can be used to enable communication between APs that utilize the same interface. Although the XATMI interface is discussed below in somewhat greater detail, further information on the XATMI interface is available in Distributed Transaction Processing: The XATMI Specification, X/Open Company Limited, U.K., (1993) (hereinafter "the XATMI Specification"), which is incorporated herein by reference in its entirety.
The TM-RM interface 28 is used for purposes of transaction control (preparing, committing, or rolling-back). The TM-RM interface 28 is described further in XA Interface, Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K. (1992). The TM-CRM interface 30 is described further in X/Open Preliminary Specification--Distributed Transaction Processing: The XA+ Specification, X/Open Company Limited, U.K. (1993).
In addition to the foregoing application programming interfaces, systems that implement the X/Open DTP model can communicate with each other using an industry standard communications protocol know as Open Systems Interconnection (OSI) Transaction Processing (TP) (ISO/IEC 10026) ("the OSI TP Standard"), all parts of which are hereby incorporated by reference in their entireties. The OSI TP Standard defines a machine independent protocol that supports communications between computers in a transaction processing system. An industry standard CRM-OSI TP programming interface, called XAP-TP 32, provides an interface between a CRM 20 and an OSI TP protocol machine 34 that conforms to the OSI TP Standard. ISO/IEC 10026-3, Information Technology - Open Systems Interconnection - Distributed Transaction Processing - Part 3: Protocol Specification ("the OSI TP Protocol Specification") defines the state transitions and protocols that a conformant OSI TP protocol machine must generate in processing OSI TP service requests in accordance with the OSI TP Standard. The XAP-TP programming interface is specified in X/Open ACSE/Presentation: Transaction Processing API (XAP-TP) CAE specification ("the XAP-TP Specification"). The XAP-TP Specification defines the interface, including functions, parameters, and errors, that controls the use of a conformant OSI-TP protocol machine. An implementation of lower layer communication protocols 36 handles the low-level communication chores needed to send information between systems 10 and 12 via a network 38. These lower layer protocols can, for example, be OSI or TCP/IP. The X/Open DTP model does not define an interface to these lower layers.
The XATMI API provides a set of function calls, collectively referred to as the tp*() function calls, that can be called to perform various functions. Table 1 is a list of these functions, callable from any C language application program.
TABLE 1 Service Request (Function Calls) of the XATMI API. Name Description Typed Buffer Functions tpalloc() Allocate a typed buffer. tpfree() Free a typed buffer. tprealoc() Change the size of a typed buffer. tptypes() Determine information about a typed buffer. Function for Writing Service Routines. tpservice() Template for service routines. tpreturn() Return from a service routine. Functions for Dynamically Advertising Service Names tpadvertise() Advertise a service name. tpunadvertise() Unadvertise a service name. Functions for Request/Response Services tpcall() Send a service request. tpcall() Send a service request and synchronously awaits its reply. tpcancel() Cancel a call descriptor for an outstanding reply. tpgetrply() Get a reply from a previous service request. Functions for Conversational Services tpconnect() Establish a conversational service connection. tpdiscon() Terminate a conversational service connection abortively. tprecv() Receive a message in a conversational connection. tpsend() Send a message in a conversational connection.
Each of the foregoing XATMI API requests has a formal syntax that specifies that format and arguments of each request. The formal syntax for each request is specified in the XATMI Specification.
Microsoft Corporation has recently introduced a product called Microsoft.RTM. Transaction Server (MTS) that provides a component-based programming model and execution environment for developing and deploying distributed applications. "Microsoft," "windows," and "Windows NT" are registered trademarks of Microsoft Corporation.
MTS allows users to build three tier applications. Client applications may be either DCOM or IIS applications. MTS becomes the middle tier supporting reusable business logic, and the data store becomes the third tier. The technology is based on the idea of building reusable components in the form of COM objects that comprise all business logic. Examples of such components include the following types: Query: data inputted, then the component binds to the data store to get the information; Update; execute a transaction and send a message to update a data base.
In the MTS environment, a client application requests an instance of an MTS component to perform a given task. The MTS component provides the business logic associated with that task. When a client application makes a request for a component instance, MTS instantiates the MTS component and returns a reference to the client application. Every instance of an MTS component has an associated context object that holds information about the MTS component. The context object of each MTS component exposes an IObjectContext interface comprising a number of methods. Two methods relating to transaction processing are IObjectContext::SetComplete () and IObjectContext::SetAbort (). An MTS component invokes SetComplete () when it has successfully completed executing its work. SetAbort () is invoked if the work is not completed successfully. A global method provided by MTS, called GetObjectContext (), is used to obtain a reference to the IObjectInterface of a context object.
MTS components (i.e., COM objects) are written as single thread units and the MTS executive handles any concurrency issues. MTS enables developers to collect a series of such components into a package to make deployment easier. Unlike with the X/Open DTP model, the MTS component developer does not have to worry about how components will be combined into global transactions. MTS components are written as all-encompassing units and are configured as either requiring or supporting a transaction, or having non-transactional properties. When an MTS component is instantiated, MTS validates its transactional properties, and if the MTS component is configured to be transactional, MTS instantiates the component with those properties. An MTS component that is instantiated with transactional properties will enlist (i.e., join) in a transaction, if one is in progress.
A Distributed Transaction Coordinator (MS DTC) within the MTS environment controls the enlistment of components in global transactions, and also coordinates transaction commitment. The MS DTC implements two-phase commitment processing. Unlike the X/Open DTP model, however, MTS transactions are not demarked by the client application as having a beginning and end. Rather, through the enlistment process, the life of a transaction is controlled by the MS DTC.
In any transaction processing system, each resource in the system is controlled by a resource manager that declares itself by contacting the local transaction manager. In the MTS environment, the local transaction manager is the MS DTC, and the process by which a resource manager declares itself to the MS DTC is referred to as enlistment (to be distinguished from enlistment in a transaction). After a resource manager has enlisted with the MS DTC, it waits for requests from an executing application. When a request associated with a new transaction arrives, the resource manager must also then enlist in that transaction. This ensures that the resource manager will get callbacks (i.e., indications) from the MS DTC when the transaction commits or aborts.
The MS DTC supports transactions that are distributed across two or more Windows.RTM. 95 or Windows NT.RTM. systems. Each system has a local a transaction manager - the MS DTC. All components and resource managers communicate with their local transaction managers. The transaction managers cooperatively manage transaction protocols that span systems using OLE Transaction Protocols. Further information concerning the Microsoft Transaction Server environment can be found in Database Workshop: Microsoft Transaction Server 2.0, Roger Jennings ed., Sams Publishing, 1997, and also at the Microsoft Corporation web site.
Currently, MTS interoperability for heterogeneous hosts exists through Microsoft's COMTI (COM Transaction Interface) for IBM's IMS or CICS transactions, through third party ODBC (Open Data Base Connectivity) for connection to remote host's databases, or via the XA Mapper.
COMTI allows exiting Cobol programs running on an IBM mainframe to be accessed by new window-based clients. ODBC allows access to various databases (Oracle, Informix, SQL Sequel server) by MTS components. The XA Mapper allows client applications that communicate with X/Open-compliant transaction managers to map their XA protocol to MTS's native OLE transaction protocols for inclusion of MTS controlled resources.
Unfortunately, these interoperability solutions exclude a large class of existing transaction processing systems - those that have been built according to the X/Open DTP model and that use the XATMI programming interface as the interface between an application program and a resource. Servers in these systems add business logic to control data bases which may be accessed by remote clients. The transaction managers in X/Open DTP-based systems control the coordination of transactions and the routing of messages. They also control rollback and recovery of data and synchronization of remote data managers.
The MS DTC, which provides the transaction manager function in an MTS environment, cannot currently interoperate with resources on remote servers controlled by an X/Open XATMI-compliant transaction manager. The MS DTC is not XATMI-compliant. Servers controlled by XATMI-compliant transaction managers therefore cannot participate in global OLE transactions managed by an MS DTC. Given the large installed base of client/server applications that are built upon an X/Open XATMI-compliant transaction manager, it would be desirable to provide methods and apparatus that enable an MS DTC to include such servers in a global transaction that it controls. More broadly, it would be desirable to provide the ability for any transaction processing environment that does not employ an XATMI-compliant transaction manager to be able to access, as part of a global transaction in that environment, a resource on a remote server in another environment that does operate under the control of an XATMI compliant transaction manager. The present invention satisfies that need.
In order for a COM/DCOM server application to be enabled to participate in, and initiate, a transaction which will be performed across several platforms, specific code must be added to the service. This requires knowledge on how the MTS system enforces the two-phase commit protocol. The average user developing a client application does not have this knowledge. The average user will only know that there is a specific OLTP service on the enterprise server which he or she wants to access, and further knows that there are one or more resources registered under the MTS system that are to be accessed within the same transaction.